@stephenw10 I will give it a try, and give a feedback after.

It seems this was partially fixed with 2.8.0 in that current speed does change and reports some real-looking values. The max frequency is still wrong though.

But anyway you can see if tailscale is running in Status > Services.

@JimS FYI, Possibly related, I am mentioning this in case someone has the issue. After a modem replacement I had to power cycle pfsense 2.6.2 after a power failure. I am now on 2.7.2 but have not had a power outage since so don't know if it's fixed. Could be modem timing mentioned above. In my case I could not access anything on pfsense. I posted this March 2025: The recent S33 modem failure and change to S34 caused pfsense 2.6 not to come back up after a power failure (3 this month so far!)I hope pfsense 2.7.2 can recover from a power failure like 2.6 did with the old modem. 2.6 always recovered until the modem change, strange but true. Trying to login to pfsense 2.6 returned the dreaded "502 Bad Gateway Nginx error". Had to power off/on. Waiting to see what happens to 2.7.2. I'm thinking possible ethernet driver issue with a different chip in the S34 than the S33, which may be fixed in 2.7.2

Ah, good result!

Also verify the server is actually resolving against pfSense and doesn't have some hard coded DNS built in.

Yup that also works: [2.8.0-RELEASE][admin@m370.stevew.lan]/root: pppcfg pppoe0 dev: lagg0 state: session sid: 0x12 PADI retries: 0 PADR retries: 0 time: 00:00:21 sppp: phase network authproto auto authname "Test" peerproto auto [2.8.0-RELEASE][admin@m370.stevew.lan]/root: /usr/local/sbin/pfSctl -c 'interface reload opt2' OK [2.8.0-RELEASE][admin@m370.stevew.lan]/root: pppcfg pppoe0 dev: lagg0 state: session sid: 0x7 PADI retries: 0 PADR retries: 0 time: 00:00:01 sppp: phase network authproto auto authname "Test" peerproto auto

We use lots of different 10G SFP+ at work. They do certainly vary, but rarely have over heating issues as long as they are in a high end switch/router such as Juniper, Cisco, etc. We did have quite bad over-heating issues in a TP-Link SX3008 switch. The problem was the SFP cages, so we modified the switch adding cheap self-adhesive heatsinks. Attached pictures show the main board before & after. Approx 20degC SFP temperature reduction. [image: 1750066993481-2022-08-12-13.59.18-tp-link.jpg] [image: 1750066993527-2022-08-13-17.32.41-tp-link.jpg]

@bigbig You shouldn't need to 'cron' dhclient. See for yourself : Get the driver name of the dhclient interface used (not WAN but the NIC driver name), for example 'igc0'. You'll find a file called /var/db/dhclient.leases.igc0 - have a look at it. dhclient knows when to renew, normally half way the lease duration. So if the total lease time is 300 seconds, dhclient will renew after 150 seconds. Totally insane of course, but maybe normal knowing what transport medium is used The dhclient process stays active during the wait, check : ps aux | grep 'dhclient' and it 'sleeps' until the delay is over, and it renews. Normally, dhclient doesn't fail or abort, something that can only happen, I guess, when the interface itself is 'gone'. Check the Status >System Logs > DHCP for 'dhclient' messages (issues).

@stephenw10 not sure. Anyway, just wanted to report it in case it is something that needs to be fixed for the later releases.

@stephenw10 Yeah, no NTP servers are that good. Even the 10 gigabit ones with reflectors..

Up

Hi @patient0 , Yes. You're right. I uninstaled Squid and perform "mv /usr/lib/libc++.so.1 /root" Then install Squid again and now all is fine. Thanks, Mucip:)

@frodo Thank you Netgate! Working now :-)

Hi @Gertjan, thanks for your input. To answer your questions: • Approx. 150 leases, of which 78 are static mappings (classic MAC → IP). • DHCP lease time is default at 7200, not shortened. • Based on log parsing, I see about 3–5 DHCPACKs per hour, so roughly 80–100 per day. • One active DHCP server on the LAN. • About 20 WiFi clients, managed via a UniFi Controller, connected to pfSense. • Typical clients: mostly Linux systems (servers, VMs, containers), some macOS devices, smartphones etc. No captive portal or guest networks. Let me know if I can provide any more detail.

Hmm, nothing logged before or after that? It should have tried to reconnect. If you see it again you can run pppcfg pppoe0 to see what it's doing. It will show you the connection phase and state.

Great. Thanks for testing!

Nevermind, my mistake, i tried to delete this thread but it told me i dont have permission. I had an old disconnected interface in my LAGG that I removed and it seems to have fixed the issue....so far anyway.

Not in the normal pfSense config. nginx listens on all IP addresses.

CE did come preinstalled on some Netgate devices. The Minnowboard Turbot (MBT) for example. But, yes, from 2.7.0 run certctl rehash to see the update.